-
Notifications
You must be signed in to change notification settings - Fork 14.1k
Move bootstrap configuration to library workspace #149514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Move bootstrap configuration to library workspace #149514
Conversation
This uses a build probe to figure out the current toolchain version - the only alternative to this is bespoke logic in Cargo to tell `test` when the toolchain is stable/unstable. The behaviour should be the same as when using `CFG_DISABLE_UNSTABLE_FEATURES` unless an arbitrary channel is provided to bootstrap, which I believe necessitates a fork anyway.
|
rustbot has assigned @Mark-Simulacrum. Use |
| } else { | ||
| match (mode, self.config.rust_optimize.is_release()) { | ||
| // Some std configuration exists in its own profile | ||
| (Mode::Std, true) => Some("dist"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The -Cembed-bitcode=yes has to also be enabled when the standard library is compiled without optimizations. Otherwise the resulting toolchain is unable to do LTO.
| [profile.dist] | ||
| inherits = "release" | ||
| codegen-units = 1 | ||
| debug = 1 # "limited" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this get unconditionally overridden by the value set for debuginfo-level-std?
This creates a new "dist" profile in the standard library which contains configuration for the distributed std artifacts previously contained in bootstrap, in order for a future build-std implementation to use. bootstrap.toml settings continue to override these defaults, as would any RUSTFLAGS provided. I've left some cargo features driven by bootstrap for a future patch.
Unfortunately, profiles aren't expressive enough to express per-target overrides, so this risc-v example was not able to be moved across. This could go in its own profile which Cargo would have to know to use, and then the panic-abort rustflags overrides would need duplicating again. Doesn't seem like a sustainable solution as a couple similar overrides would explode the number of lines here.
We could use a cargo config in the library workspace for this, but this then would have to be respected by Cargo's build-std implementation and I'm not yet sure about the tradeoffs there.
This patch also introduces a build probe to deal with the test crate's stability which is obviously not ideal, I'm open to other solutions here or can back that change out for now if anyone prefers.
cc @Mark-Simulacrum rust-lang/rfcs#3874